[Previous] [Next] [Index]
[Thread]
Re[2]: Java "security holes'
I believe it is still policy problem: Network admin people would prefer
to centralize the security managment, like firewall. Even if I wrongly
configure my unix workstation, the public internet sites still can not
access my workstation. If we allow individual users to open connections,
then anything could happen without acknowledging admin people.
I would like to know how Sun solve the load problems in the future.
Jing
----------------------------
Is is possible to have a "Java Properties" table in the application
that specifies the kind of behaviors allowed to an applet ? Such a
property table must be under control of the user.
I could imagine two dimensions initially, properties applied on
a source basis, and properties applied transitively, e.g. from
one applet to another perhaps based on the "least permissive" set
of properties... Almost sounds like inheritance ;-)
Hmmm.... interesting topic. I'll think some more.
John
> From owner-www-security@ns2.rutgers.edu Mon Mar 11 17:10 EST 1996
> Date: Mon, 11 Mar 1996 08:58:08 -0800
> From: mrm@doppio.Eng.Sun.COM (Marianne Mueller)
> To: ekr@terisa.com, dhudes@panix.com
> Subject: Re: Java "security holes'
> Cc: www-security@ns2.rutgers.edu
>
> We're working on adding a signed class loader to the system, to allow
> for the scenario where some authenticated class can be allowed more
> functionality.
>
> The hard part is the policy, that is, once you have an applet that you
> *know* comes from Walmart, so what? Does that mean you allow that
> applet to make connections to other Walmart applets, or does that mean
> you allow that applet to access the Walmart shopping cart which is
> implemented as a file on the client file system?
>
> (I just made up those two examples so please don't take them as some
> sort of statement about how we want to do things ...)
>
> Marianne
> JavaSoft
> mrm@eng.sun.com
>
>
Follow-Ups: